Особенности работы системы при гранулярном управлении доступом¶
Особенности работы привилегий¶
Привилегии |
Особенности работы привилегий |
|---|---|
|
Привилегии позволяют видеть в базе данных автора изменений для ГП, политик ПО, заданий автоматизации, правил сбора событий и серверных подсистем (DHCP, серверы печати и т.д.) |
|
Привилегия позволяет видеть в базе данных информацию об установленных на компьютер подсистемах |
|
Для успешной активации роль с данной привилегией должна быть назначена на корень домена (при этом признак «Включая дочерние подразделения» может быть как установлен, так и не установлен) |
|
Роль с данной привилегией должна быть привязана к корню домена с установленным признаком »Включая дочерние подразделения» |
|
Привилегия дает права на чтение дополнительных атрибутов пользователей только через API и в базе данных. Для чтения дополнительных атрибутов пользователей через интерфейс ALD Pro (вкладка «Дополнительные сведения» карточки пользователя) необходимы две привилегии:
|
|
До версии 2.4.0 привилегия распространялась на весь домен. С 2.4.0 привилегия имеет привязку к подразделению |
|
Для возможности назначения правила SUDO на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения». Для возможности назначения правила SUDO на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения» |
|
Для возможности назначения правила HBAC на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения». Для возможности назначения правила HBAC на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения». |
Особенности работы методов PUT и PATCH¶
При работе этих методов могут не возвращаться ошибки об отсутствии прав на выполнение операций на изменение сущностей.
При методах PUT и PATCH работает следующим образом:
выполняется метод GET, который возвращает сущность в текущем состоянии;
выполняется метод PUT или PATCH, который меняет сущность;
выполняется метод GET, который возвращает измененную сущность.
Если отправлять PUT или PATCH запрос с телом запроса без изменения сущности, выполняется 1-й шаг - метод GET, который возвращает сущность в текущем состоянии, а метод PUT (2-й шаг) не будет выполняться, так как запись не меняется.
В этом случае пользователю без прав на изменение сущности (методами PUT или PATCH) системой не будет выдана ошибка об отсутствии прав на операцию, т.к. эта операция не выполнялась.
Если отправить PUT или PATCH запрос с изменением от пользователя, не имеющем на это права, тогда валидация прав корректно отработает.
Возможные ответы системы на запросы GET при отсутствии прав на выполнение операции¶
При отсутствии прав на запросы GET система может выдавать следующие варианты ответов:
сообщение об ошибке на выполнение операции из-за отсутствия прав:
// {
"error": "Отсутствуют права на выполнение данной операции",
"success": false,
"code": "ForbiddenError"
}
// {
"error": "Отсутствуют права на выполнение данной операции",
"success": false,
"code": "DeniedIPAError"
}
успех операции с пустыми списками, для которых указано ненулевое количество записей:
// { "data": [], "total": 45, "success": true}
успех операции с пустыми списками, для которых возвращается ноль записей:
// { "data": [], "total": 0, "success": true}